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(54) Communication connecting device with a reliable transmission capability and a data output 
control method 



(57) A communication connecting device includes a 
terminal unit controller (12) for temporarily storing data 
received from a sending terminal unit. A packetizer/de- 
packetizer (14) collectively codes the data sequentially 
read out in accordance with size information fed from a 
size information storage (16). The packetizer/depack- 
etizer (14) determines whether or not the data is control 
data and delivers, if the answer of the decision is posi- 
tive, a notification control signal to a control data monitor 



(22). A UDPTL (facsimile User Datagram Protocol 
Transport Layer protocol) controller (1 8) feeds a UDPTL 
packet input from the packetizer/depacketizer (14) to 
the control data monitor (22) in accordance with ITU-T 
(International Telecommunication Union-Telecommuni- 
cation standardization sector) Recommendation T.38. 
The control data monitor (22) repeatedly sends the 
UDPTL packet on the basis of the notification control 
signal. 
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Description 

BACKGROUND OF THE INVENTION 
Field of the Invention 



[0001] The present invention relates to a communica- 
tion connecting device and a data output control method 
advantageously applicable to, e.g., a gateway that con- 
nects a G3 (Group 3) facsimile apparatus to an IP (In- 
ternet Protocol) network. More particularly, the present 
invention relates to a communication connecting device 
and a data output control method feasible for a real-time 
facsimile apparatus or terminal for sending UDP (User 
Datagram Protocol)/!P packets while monitoring the da- 
ta of the packets. 

[0002] Generally, for real-time facsimile communica- 
tion over an IP network, a system configuration pro- 
posed by the ITU-T (International Telecommunication 
Union-Telecommunication standardization sector) Rec- 
ommendation T38 is used. In this system configuration, 
an Internet facsimile apparatus or gateway is connected 
to the IP network at each of the transmitter and receiver 
sides. The Internet facsimile apparatuses each are con- 
nected to a particular G3 facsimile apparatus by a PSTN 
(Public Switched Telephone Network). 
[0003] The Internet facsimile apparatus at the trans- 
mitter side receives data from the sending G3 facsimile 
apparatus and temporarily stores the data. The facsim- 
ile apparatus then packetizes the data by referencing 
packet size information fed thereto. The resulting pack- 
ets are referred to as IFP (internet Facsimile Protocol) 
packets. 

[0004] UDP is applied to communication between the 
Internet facsimile apparatuses. For example, a UDP 
header is added to the head of a UDP payload storing 
data. Even when UDP packet data is lost, UDP does not 
execute processing for reconstructing the packet data. 
[0005] Specifically, the Internet facsimile apparatus at 
the transmitter side temporarily stores the IFP packets 
to be sent. The Internet facsimile apparatus then writes 
every new IFP packet in the primary field of its storage 
area to thereby generate a UDPTL (facsimile UDP 
Transport Layer protocol) payload and send the UDPTL 
payload to the IP network. In addition, to prepare for the 
loss of the UDP packet data, the Internet facsimile ap- 
paratus writes the UDP packets sent in the past in the 
secondary field of the storage area to thereby form a 
UDPTL payload although the past UDP packets are re- 
dundant. Sequence numbers unique to the primary field 
are attached to the primary field. A UDPTL header is 
added to the head of the UDPTL payload to complete a 
UDPTL packet. The UDP payload is constituted by such 
a UDPTL packet. A UDP packet is made up of a UDP 
header and a UDP payload. 

[0006] After an IP header has been added to a UDP 
packet to form an IP packet, the IP packet is sent to the 
Internet facsimile apparatus at the receiver side via the 



IP network. 

[0007] The Internet facsimile apparatus at the receiv- 
er side decomposes the received IP packet to the level 
of UDPTL packets. The Internet facsimile apparatus 
5 then classifies, among the decomposed UDPTL pack- 
ets, IFP packets to be used and then depacketizes the 
classified IFP packets by decoding them, thereby restor- 
ing the original data. The Internet facsimile apparatus 
temporarily stores the restored data and then sends 
10 them to the receiving G3 facsimile apparatus. 

[0008] In the above-described communication sys- 
tem, control data included in a V.21 channel 2 signal, 
which is based on Recommendation T.30, is sent and 
received the same number of times as image data. Staf- 
fs ed another way, the control data and image data are 
equivalent to each other as to the reliability of transfer 
over the IP network. However, should the control data 
be not surely sent or received, communication would 
end in a defective way. It is therefore preferable that the 
20 control data be sent and received with higher reliability 
than image data. 

[0009] As to communication using the UDP protocol 
proposed by Recommendation T.38, the sending inter- 
net facsimile apparatus sets IFP packets in the primary 
25 and secondary fields a plurality of times to thereby send 
data with redundancy, as stated earlier. While this kind 
of scheme is directed toward reliable communication, it 
fails to insure reliable transmission of control data to a 
destination. 

30 

SUMMARY OF THE INVENTION 



[0010] It is an object of the present invention to pro- 
vide a communication connecting device and a data out- 
35 put control method capable of distinguishing the kinds 
of data to be sent to thereby enhance reliable transmis- 
sion of control data. 

[0011] In accordance with the present invention, a 
communication connecting device is connected at one 
40 end to a first terminal unit and connected at the other 
end to a second terminal unit via an IP network, and se- 
lectively operable with a plurality of communication 
standards adaptive to the first terminal unit, second ter- 
minal unit and IP network forthereby implementing real- 
45 time communication. The communication connecting 
device includes a terminal unit control circuit for storing 
data received from the first terminal unit or the second 
terminal unit, and controlling the first terminal unit in ac- 
cordance with a first communication standard. A first 
so storage stores size information representative of the 
size of data to be collectively coded. A coding/decoding 
circuit collectively codes the data in accordance with the 
size information read out of the first storage and the first 
communication standard and determines whether or not 
55 the data is control data relating to control of data or de- 
codes coded data received from the second terminal 
unit in accordance with the first communication stand- 
ard. A second storage stores, assuming the loss of the 
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coded data output from the coding/decoding circuit, the 
coded data. An information adding/separating circuit 
adds a header and data, which makes up for the loss of 
the coded data assumed, to the coded data in accord- 
ance with a second communication standard relating to 
the IP network or separates coded data from data re- 
ceived from the second terminal unit and feeds the sep- 
arated coded data to the coding/decoding circuit. A con- 
trol monitoring circuit causes, in response to a notifica- 
tion control signal output from the coding/decoding cir- 
cuit to show that the data is the control data, the control 
data to be repeatedly read out of the second storage. 
An interfacing circuit converts the coded data input via 
the control monitoring circuit to a signal based on a com- 
mand or converts a signal received from the second ter- 
minal unit to the coded data. 

[001 2] Also, in accordance with the present invention, 
a data output control method applicable to a communi- 
cation connecting device of the type described begins 
with a step of storing data received from the first terminal 
unit or the second terminal unit. Size information repre- 
sentative of the size of data to be collectively coded is 
output. The data read out in accordance with the size 
information and a first communication standard are col- 
lectively coded. Subsequently whether or not coded da- 
ta produced in the second step is control data for control 
of data is determined. A notification control signal is out- 
put if the coded data is control data. The coded data are 
stored on the assumption of the loss of the coded data. 
A header for the coded data and the coded data stored 
on the assumption of the loss of the coded data are read 
out in accordance with a second communication stand- 
ard relating to the IP network and combined. The control 
data read out a plurality of times in response to the no- 
tification control signal are sent with the transmission 
condition of the control data being monitored. The coded 
data are converted to a signal based on a command and 
then output. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0013] The objects and features of the present inven- 
tion will become more apparent from consideration of 
the following detailed description taken in conjunction 
with the accompanying drawings in which: 

FIG. 1 is a schematic block diagram showing a pre- 
ferred embodiment of the communication connect- 
ing device in accordance with the present invention 
and implemented as an Internet facsimile appara- 
tus by way of example; 

FIG. 2 is a schematic block diagram showing a spe- 
cific configuration of a control data monitor included 
in the illustrative embodiment; 
FIG. 3 is a schematic block diagram showing gate- 
ways connected to each other via an IP network and 
each being implemented by the Internet facsimile 
apparatus shown in FIG. 1; 



FIG. 4 shows a table useful for understanding a re- 
lation between IFP packets and the primary and 
secondary fields of UDPTL packets; 
FIG. 5 shows how FIGS. 5A and 5B are combined; 
5 FIGS. 5A and 5B demonstrate a specific conven- 

tional Internet facsimile communication sequence; 
and 

FIG. 6 shows an Internet facsimile communication 
sequence unique to the illustrative embodiment. 

10 

DESCRIPTION OF THE PREFERRED EMBODIMENT 

[0014] Referring to FIG. 1 of the drawings, an Internet 
facsimile apparatus or terminal (Internet FAX hereinaf- 

15 ter) 1 0 to which a communication connecting device em- 
bodying the present invention is applied will be de- 
scribed. Part of the Internet FAX 10 not relevant to the 
understanding of the present invention is neither shown 
nor will be described specifically. Signals are designated 

20 by reference numerals attached to signal lines on which 
they appear. 

[0015] As shown in FIG. 1, the Internet FAX 10 in- 
cludes a FAX controller 12, a packetizer/depacketizer 
14, a size information storage 16, a UDPTL controller 

25 18, a buffer 20, a control data monitor 22, and a LAN 
(Local Area Network) controller 24. An analog G3 fac- 
simile apparatus (G3 FAX hereinafter) 30 is connected 
to the Internet FAX 1 0 and operates in accordance with 
Recommendation T.30 (revised in 1996). 

30 [0016] The FAX controller 1 2 includes a non-destruc- 
tive memory for storing data and has an interface func- 
tion for converting signals meant for the G3 FAX 30, al- 
though not shown specifically. The non-destructive 
memory is capable of repeatedly outputting data 32 in- 

35 put from the G3 FAX 30. The FAX controller 12 selec- 
tively controls the write-in of the data 32 or the read-out 
of data 34 in accordance with a control signal fed from 
a system controller not shown. The data 34 read out of 
the memory are fed to the packetizer/depacketizer 14. 

40 When the Internet FAX 10 is a receiving terminal, the 
packetizer/depacketizer 14 depacketizes received data 
while the FAX controller 12 stores the resulting depa- 
ketized and decoded data 34. 

[0017] The packetizer/depacketizer 14 includes a 
45 packetizing circuit and a depacketizing circuit although 
not shown specifically. The size information storage 16 
stores information representative of the size of a single 
packet beforehand. The storage 16 feeds packet size 
information 36 to the packetizer/depacketizer 14. The 
50 packetizing circuit divides the input data 34 into packets 
each having the packet size indicated by the information 
16. The packetizing circuit then delivers coded IFP 
packets 38 to the buffer 20 and UDPTL controller 18. 
The depacketizing circuit decodes and depacketizes 
55 coded IFP packets 38 input from the UDPTL controller 
18. 

[0018] The packetizer/depacketizer 14 additionally in- 
cludes a decision circuit for determining whether or not 
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the input data 34 is control data, although not shown 
specifically. If the data 34 is control data, then the deci- 
sion circuit feeds a notification control signal 40 to the 
control data monitor 22. 

[0019] The UDPTL controller 18 produces a UDPTL 
payload including the IFP packet data 38 in accordance 
with Recommendation T.38. The UDPTL payload con- 
sists of a primary field corresponding to a packet number 
and a secondary field storing an IFP packet or packets 
having been sent. More specifically, the past data stored 
in the buffer 20 are fed to the secondary field although 
redundant. If desired, an error correction code may be 
fed to the secondary field in addition to the past data. 
The IP packet data 38 are delivered also to the buffer 
20 via the UDPTL controller 18 and a signal line 42. 
[0020] The UDPTL controller 1 8 adds a UDPTL head- 
er to the head of the UDPTL payload to thereby com- 
plete a UDPTL packet, which is a UDP payload. The 
UDPTL controller 18 delivers the UDPTL packet 44 to 
the control data monitor 22. 

[0021] In the event of receipt, a received UDPTL 
packet 44 having the above-described layered data 
structure is input to the UDPTL controller 18. The 
UDPTL controller 1 8 divides the received UDPTL pack- 
et 44 into IFP packets and then feeds necessary IFP 
packet data 38 to the packetizer/depacketizer 14. 
[0022] As shown in FIG. 2 specifically, the control data 
monitor 22 includes a timer 220, a time-over decision 
circuit 222, and a data retransmission controller 224. 
While monitoring the data, the control data monitor 22 
directly delivers the UDPTL packet 44 to the LAN con- 
troller 24 as a UDPTL packet 46. A timing signal 226 is 
input to the timer 220 when the last one of a sequence 
of data to be sent is fed from the control data monitor 
22 to the LAN controller 24. In response to the timing 
signal 226, the timer 220 starts counting time and inter- 
mittently feeds a period of time 230 to the time-over de- 
cision circuit 222 at preselected intervals. Subsequently, 
the timer 220 stops counting time in response to a timing 
signal 228 input thereto when a receiving terminal re- 
turns an answer on the receipt of the data. 
[0023] The time-over decision circuit 222 compares 
the period of time 230 fed from the timer 220 with a 
preselected reference period of time T If the period of 
time 230 is longer than the reference period of time T, 
then the time-over decision circuit 222 determines that 
time is over, and feeds an error signal 232 to the data 
retransmission controller 224. When the time-over de- 
cision circuit 222 receives the period of time 230 after 
the time-over, the circuit 222 may or may not output the 
error signal 232 again. 

[0024] The notification control signal 40 output from 
the packetizer/depacketizer 14, FIG. 1, is also input to 
the data retransmission controller 224. The notification 
control signal 40 and error signal 232 enable the data 
retransmission controller 224 when input thereto togeth- 
er. In the enabled state, the data retransmission control- 
ler 224 delivers a retransmission control signal 234 to 



the UDPTL controller 18 and buffer 20. When control 
data is fed or when time-over occurs, the UDPTL packet 
46 is again delivered to the LAN controller 24 under the 
control of the control data monitor 22 as data to be re- 
5 transmitted. 

[0025] In the illustrative embodiment, the control data 
monitor 22 feeds the retransmission control signal 234 
to the UDPTL controller 18 and buffer 20, as stated 
above. Alternatively, the monitor 22 may include a buffer 
10 memory, not shown, for storing the UDPTL packet 36. 
In such a case, the monitor 22 stores the UDPTL packet 
46 while delivering it to the LAN controller 24 and then 
reads out the UDPTL packet 46 and again transmits it 
at the next output timing. 
15 [0026] Further the above-mentioned buffer memory 
of the control data monitor 22 may be replaced with an 
exclusive region formed in the buffer 20 for storing the 
UDPTL packet 44. In this case, the UDPTL controller 18 
delivers the UDPTL packet not only to the control data 
20 monitor 22 but also to the buffer 20 so as to store it for 
a moment. In the event of retransmission, the control 
data monitor 22 feeds the retransmission control signal 
234 to the buffer 20 in order to read the UDPTL packet 
44 out of the buffer 20. The UDPTL packet 44 is then 
25 routed through the signal line 42 and control data mon- 
itor 22 to the LAN controller 24. 

[0027] Referring again to FIG. 1, the LAN controller 
24 adds a UDP header to the UDPTL packet or UDP 
payload 46 to thereby complete a UDP packet. Assume 
30 that data are interchanged by use of an IFP/UDPTL/ 
UDP/IP layer model by way of example. Then, a UDP 
packet corresponds to an IP payload. In this case, the 
LAN controller 24 adds an IP header to an IP payload 
to thereby generate an IP packet. The LAN controller 24 
35 transforms the IP packet 46 to an analog signal and 
sends the analog signal 48 to the IP network 100. The 
LAN controller 24 additionally has an interface function 
for matching the level of an electric signal to a protocol 
assigned to the IP network. 
40 [0028] As stated above, the Internet FAX 10 outputs 
control data more frequently than in the case of trans- 
mission of other data, e.g., image data. 
[0029] In the sending G3 FAX or terminal unit 30, a 
scanner, not shown, transforms data read out of a doc- 
45 ument to a corresponding electric signal and sends the 
electric signal in accordance with the G3 standard, 
which is proposed by Recommendation T.30. Specifi- 
cally, the operator of the G3 FAX 30 lays documents, 
which are paper sheets or similar recording media, on 
so a tray, not shown, which is mounted on the G3 FAX 30. 
The operator then inputs a read command on an oper- 
ation panel, not shown, also mounted on the G3 FAX 
30. In response, the scanner starts scanning the docu- 
ments with light. The scanner senses the intensity of re- 
55 flection from part of each document where data is 
present and the intensity of reflection from the other part 
of the same and transforms each of them to a corre- 
sponding electric signal. An analog-to-digital converter, 
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not shown, digitizes the electric signal and outputs the 
resulting digital signal or data 32 having tonality. The da- 
ta 32 are sent to the FAX controller 12 via a PSTN 32. 
[0030] As shown in FIG. 3. the real-time Internet FAX 
10 is connected to another real-time Internet FAX 110 
via an IP network 100. The Internet FAX 110 is connect- 
ed to a G3 FAX 120 via a PSTN 32a. It will be seen that 
the Internet FAX 10, IP network 100 and Internet FAX 
110 constitute a communication domain conforming to 
the Recommendation T 38 protocol. The PSTN 32a be- 
tween the Internet FAX 110 and the G3 FAX 120 con- 
forms to the Recommendation T.30 protocol. The sys- 
tem shown in FIG. 3 terminals at the G3 FAXs 30 and 
120. 

[0031] A real-time facsimile communication se- 
quence generally executed by the system of FIG. 3 will 
be described hereinafter. The UDPTL controller 18, FIG. 
1 , writes every IFP packet in the primary field as new 
data while writing the past data sent in the secondary 
field in accordance with Recommendation T.38, thereby 
generating a UDPTL packet. 

[0032] Specifically, a UDP payload generated by the 
UDPTL controller 18 includes a UDPTL header and a 
UDPTL payload, as stated earlier. FIG . 4 shows the data 
structure of a UDPTL payload. As shown, the UDPTL 
payload includes a primary and a secondary field. In the 
illustrative embodiment, the secondary field is made up 
of a first and a second secondary field 1 and 2, respec- 
tively The packetizer/depacketizer 14, FIG. 1 . feeds the 
IFP packets to the buffer 20, FIG. 1 , under the control 
of the system controller as stated previously. The IFP 
packets are written to the primary field. The UDPTL con- 
troller 18 sequentially shifts the IFP packets read out of 
the buffer 20 from the secondary field 1 to the secondary 
field 2 in accordance with the number of times of trans- 
mission. Two or more IFP packets may be written to the 
secondary fields, if necessary. 

[0033] Three IFP packets are stored in a UDPTL 
packet at positions shown in FIG. 4. In FIG. 4, numbers 
(Nos.) attached to the IFP packets are not sequence 
numbers originally given during transmission or receipt, 
but are serial numbers for easy, convenient identifica- 
tion of the packets. The serial numbers each identify a 
particular stored packet. FIG. 4 shows a specific case 
wherein eighty-six IFP packets are dealt with. 
[0034] Reference will be made to FIGS. 5A and 5B for 
describing a conventional real-time communication se- 
quence effected with the eighty-six IFP packets shown 
in FIG. 4. Numbers 01 through 86 shown in FIGS. 5A 
and 5B are the serial numbers attached to the IFP pack- 
ets, but have nothing to do with sequence numbers in 
the UDPTL packet. Also, in FIGS. 5A and 5B, packets 
shown on the IP network 100 between the Internet FAXs 
1 0 and 110 are representative of the primary field of the 
UDPTL packet. 

[0035] First, as shown in FIG. 5A, the receiving G3 
FAX 120 sends four consecutive commands CED 
(CallEd station iDentification) tone, Flags, CSI (Called 



Station Identification) and DIS (Digital Identification Sig- 
nal) to the Internet FAX 110. In response, IFP packets 
respectively corresponding to the received commands 
are input to the UDPTL controller of the Internet FAX 

s 110. The UDPTL controller generates, based on Rec- 
ommendation T.38, UDPTL packets each storing partic- 
ular initial data (numbers 02 through 06; control data 
CSI/DIS according to Recommendation T.30). The In- 
ternet FAX 1 1 0 packetizes the received UDPTL packets 

10 and sends the resulting IP packet to the Internet FAX 10 
over the IP network 100. The Internet FAX 10 separates 
the UDPTL packets and IFP packets from the UDP pay- 
loads of the IP packet and decodes the separated pack- 
ets, thereby reconstructing the four commands. The In- 

* 5 ternet FAX 1 0 then sends the four commands to the G3 
FAX 30. 

[0036] The transmitting G3 FAX 30 packetizes four 
commands Flags, TSI (Transmitting Station Identifica- 
tion), DCS (Digital Command Signal) and TCF (Training 

20 Check) corresponding to the received four commands. 
The G3 FAX 30 then sends the resulting UDPTL packets 
(IFP packets numbers 07 through 1 0) to the G3 FAX 1 20 
via the Internet FAXs 10 and 110. 
[0037] Subsequently, as shown in FIG. 5B, the receiv- 
es ing G3 FAX 120 sends two commands Flags and CFR 
(ConFirmation to Recieve) to the Internet FAX 110. The 
Internet FAX 1 1 0 packetizes the received commands in- 
to three packets (11 through 13) and sends them to the 
sending G3 FAX 30 via the Internet FAX 10 as recon- 

30 structed commands. In response, the sending G3 FAX 
30 sends a training command (Training), determining 
that communication has been set up. The training com- 
mand controls a modem, not shown, included in the re- 
ceiving G3 FAX 120. Thereafter, the sending G3 FAX 

35 30 sequentially sends stored image data and com- 
mands Flags and EOP to the Internet FAX 10. In re- 
sponse, the Internet FAX 10 sends to the Internet FAX 
110 IFP packets numbers 15 through 81 as image data 
and IFP packets numbers 82 through 83 as commands 

40 Flags and EOP/FCS (End Of Procedure/Frame Check 
Sequence). The Internet FAX 110 sends the received 
image data and reconstructed two commands Flags and 
EOP to the G3 FAX 120. Finally, G3 FAX 120 sends 
Flags, MCF (Message ConFirmation) and MCF/FCS 

45 (Message ConFirmation/Frame Check Sequence) for 
message confirmation to G3 FAX 30 via the Internet 
FAXs 1 1 0 and 1 0. Then, the conventional real-time com- 
munication sequence for image data ends. 
[0038] As the sequence shown in FIGS. 5A and 5B 

50 indicates, control data including flags and commands 
have customarily been sent only the same number of 
times as image data. The Internet FAXs 1 0 and 1 1 0 each 
send, based on Recommendation T.38, a UDPTL pack- 
et storing not only the current data but also the past data 

55 in its secondary field. While this promotes sure commu- 
nication, the feed of control data available at the current 
stage of development is not fully satisfied in reliability 
yet. 
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[0039] In light of the above, in the illustrative embod- 
iment, the packetizer/depacketizer 14 determines 
whether or not data fed from the FAX controller 12 is 
control data. If the input data is control data, then the 
packetizer/depacketizer 14 delivers the notification con- 
trol signal 40 to the control data monitor 22. In response 
to the signal 40 or when time-over occurs, the control 
data monitor 22 again sends the control data. This pro- 
cedure unique to the illustrative embodiment will be de- 
scribed more specifically with reference to FIG. 6. 
[0040] FIG. 6 demonstrates the transmission from the 
receiving Internet FAX 110 in order to clearly show the 
difference between the sequence of the illustrative em- 
bodiment and the conventional real-time communica- 
tion sequence. Because the structural elements of the 
Internet FAX 110 are identical with the structural ele- 
ments of the Internet FAX 1 0, the former is designated 
by the same reference numerals as the latter. 
[0041] First, the FAX controller 12 feeds a flag to the 
packetizer/depacketizer 14 (T10). The packetizer/de- 
packetizer 14 packetizes the flag and then delivers it to 
the UDPTL controller 14. At the same time, the pack- 
etizer/depacketizer 14 determines that the flag is control 
data, and feeds the notification control signal 40 to the 
control data monitor 22 (T12). The UDPTL controller 18 
determines that the input IFP data is meant for the pri- 
mary field, and writes it in the primary field of the buffer 
20. At this stage, no data are stored in the secondary 
field. 

[0042] The UDPTL controller 18 combines the IFP 
flag packet and the data of the secondary field to thereby 
produce a UDPTL payload. The controller 1 8 then adds 
a UDPTL header to the UDPTL payload for thereby gen- 
erating a UDPTL packet (T14) and delivers the UDPTL 
packet to the LAN controller 24 via the control data mon- 
itor 22 (T16). The control data monitor 22, already in- 
formed of the fact that the UDPTL packet is control data, 
feeds the retransmission control signal 234 to the 
UDPTL controller 18 and buffer 20. In response, the 
UDPTL controller 1 8 again generates the UDPTL pack- 
et and delivers it to the control data monitor 22. Conse- 
quently, the control data monitor 22 again sends the 
UDPTL packet representative of the flag. If desired, the 
control data monitor 22 may repeat the transmission in 
the step T1 6 for the delivery of the UDPTL packet to the 
LAN controller 24 (T16). 

[0043] Subsequently, the FAX controller 12 feeds a 
CSl signal to the packetizer/depacketizer (T20). The 
packetizer/depacketizer 14 packetizes the CSl signal 
and delivers the resulting packet to the UDPTL control- 
ler 1 8. At the same time, the packetizer/depacketizer 14 
determines that the CSl signal is control data, and feeds 
the notification control signal 40 to the control data mon- 
itor 22 (T22). The UDPTL controller 18 determines that 
the input IFP packet is meant for the primary field, and 
writes it in the primary field of the buffer 20. At this stage, 
the flag data is present in the secondary field. 
[0044] The UDPTL controller 18 combines the IFP 
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CSl signal packet and the flag data of the secondary 
field to thereby produce a UDPTL payload. The control- 
ler 1 B then adds a UDPTL header to the UDPTL payload 
for thereby generating a UDPTL packet (T24) and de- 
5 livers the UDPTL packet to the LAN controller 24 via the 
control data monitor 22 (T26). Again, the control data 
monitor 22, already informed of the fact that the UDPTL 
packet is control data, feeds the retransmission control 
signal 234 to the UDPTL controller 1 8 and buffer 20. In 
w response, the UDPTL controller 1 8 again generates the 
UDPTL packet and delivers it to the control data monitor 
22. Consequently, the control data monitor 22 again 
transmits the UDPTL packet representative of the CSl 
signal and flag (T28). Again, the control data monitor 22 
15 may repeat the transmission processing in the step T26 . 
[0045] Further, the FAX controller 12 feeds a digital 
identification signal (DIS signal hereinafter) to the pack- 
etizer/depacketizer 14 (T30). The packetizer/depack- 
etizer 1 4 packetizes the DIS signal and feeds the result- 
20 ing packet to the UDPTL controller 1 8 . At the same time , 
the packetizer/depacketizer 14 determines that the DIS 
signal is control data, and feeds the notification control 
signal 40 to the control data monitor 22 (T32). The 
UDPTL controller 1 8 determines that the input IFP pack- 
25 et is meant for the primary field, and writes it in the pri- 
mary field of the buffer 20. At this stage, the CSl signal 
and flag data are present in the secondary field. 
[0046] The UDPTL controller 18 combines the IFP 
DIS signal packet and the CSl signal and flag data of 
30 the secondary field to thereby produce a UDPTL pay- 
load. The controller 18 then adds a UDPTL header to 
the UDPTL payload for thereby generating a UDPTL 
packet (T34) and delivers the UDPTL packet to the LAN 
controller 24 via the control data monitor 22 (T36). 
35 Again, the control data monitor 22, already informed of 
the fact that the UDPTL packet is control data, feeds the 
retransmission control signal 234 to the UDPTL control- 
ler 1 8 and buffer 20. In response, the UDPTL controller 
18 again generates the UDPTL packet and delivers it to 
40 the control data monitor 22. Consequently, the control 
data monitor 22 again transmits the UDPTL packet rep- 
resentative of the DIS signal, CSl signal and flag (T38). 
Again, the control data monitor 22 may repeat the trans- 
mission processing in the step T36. 
45 [0047] By contrast, data Speed and image data 
Imagel and Image2 each are sent only once in the form 
of a packet. This is because the packetizer/depacketizer 
14 determines that such data are not control data, and 
does not output the notification control signal 40. 
so [0048] As stated above, when data, including data 
meant for the redundant secondary field of Recommen- 
dation T.38, is control data, the illustrative embodiment 
sends the control data a plurality of times during a single 
real-time communication sequence. That is, the illustra- 
55 tive embodiment repeatedly sends the control data 
while distinguishing it from, e.g., image data. This real- 
izes far more reliable transmission of control data than 
the conventional sequence. The control data can there- 
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fore be sent to the destination surely enough to obviate 
the defective end of communication. 
[0049] It is noteworthy that control data, as distin- 
guished from image data, is low in transmission rate and 
therefore does not need a frequency band as broad as 5 
a frequency band assigned to image data in spite of the 
repeated transmission. This obviates a short frequency 
band despite the repeated transmission of control data. 
While the illustrative embodiment has been shown and 
described as sending only control data a plurality of 10 
times, it may send even all IFP packets a plurality of 
times. The Internet FAXs 10 and 110 each may be pro- 
vided with the function of a G3 facsimile apparatus. 
[0050] Of course, the present invention is not limited 
to an Internet facsimile apparatus for real-time facsimile 15 
communication, but can repeatedly send control data 
even with software. 

[0051] In summary, it will be seen that the present in- 
vention provides a communication connecting device 
capable of obviating the defective end of communication 20 
and insuring real-time communication. The device of the 
present invention therefore promotes the transmission 
of control data over an IP network far surer than the 
transmission of image data. 

[0052] The entire disclosure of Japanese patent ap- 25 
plication No. 2000-255727 filed on August 22, 2000, in- 
cluding the specification, claims, accompanying draw- 
ings and abstract of the disclosure is incorporated here- 
in by reference in its entirety. 

[0053] While the present invention has been de- 30 
scribed with reference to the particular illustrative em- 
bodiment, it is not to be restricted by the embodiment. 
It is to be appreciated that those skilled in the art can 
change or modify the embodiment without departing 
from the scope and spirit of the present invention. 35 

Claims 

1. A communication connecting device (10, 110) con- 40 
nected at one end to a first terminal unit (30, 120) 
and connected at the other end to a second terminal 
unit (30, 120) via an IP network (100), and selec- 
tively operable with a plurality of communication 
standards adaptive to said first terminal unit (30, 45 
120), said second terminal unit (30, 120) and said 
IP network (1 00) for thereby implementing real-time 
communication, 

CHARACTERIZED BY comprising: 

so 

a terminal unit control circuit (1 2) for storing da- 
ta received from the first terminal unit (30, 120) 
or the second terminal unit (30, 120), and con- 
trolling said first terminal unit (30, 120) in ac- 
cordance with a first communication standard; 55 
a first storage (1 6) storing size information rep- 
resentative of a size of data to be collectively 
coded; 



a coding/decoding circuit (14) for collectively 
coding the data in accordance with the size in- 
formation read out of said first storage (1 6) and 
the first communication standard and determin- 
ing whether or not said data is control data re- 
lating to control of data or decoding coded data 
received from the second terminal unit in ac- 
cordance with said first communication stand- 
ard; 

a second storage (20) for storing, assuming a 
loss of the coded data output from said coding/ 
decoding circuit (14), said coded data; 
an information adding/separating circuit (18) 
for adding a header and data, which makes up 
for the loss of the coded data assumed, to said 
coded data in accordance with a second com- 
munication standard relating to the IP network 
or separating coded data from data received 
from the second terminal unit (30, 120) and 
feeding said coded data separated to said cod- 
ing/decoding circuit (14); 

a control data monitoring circuit (22) for caus- 
ing, in response to a notification control signal 
output from said coding/decoding circuit (13) to 
show that the data is the control data, said con- 
trol data to be repeatedly read out of said sec- 
ond storage (20); and 

an interfacing circuit (24) for converting the 
coded data input via said control data monitor- 
ing circuit (22) to a signal based on a command 
orconverting a signal received from the second 
terminal unit (30, 120) to the coded data. 

2. The device in accordance with claim 1 , CHARAC- 
TERIZED IN THAT said coding/decoding circuit 
(14) comprises a data discriminating circuit for de- 
termining whether or not the coded data is the con- 
trol data, and outputting the notification control sig- 
nal if said coded data is said control data. 

3. The device in accordance with claim 1 , CHARAC- 
TERIZED IN THAT said control data monitoring cir- 
cuit (22) comprises: 

a timer (220) for starting counting time in re- 
sponse to an output of the control data to there- 
by count a period of time up to a receipt of an 
answer to said control data from a destination; 
a comparing circuit (222) for comparing the pe- 
riod of time counted by said timer (220) and a 
preselected reference period of time; and 
a retransmission control circuit (224) for caus- 
ing, when said comparing circuit (222) deter- 
mines that the period of time counted is longer 
than the reference period of time, the control 
data sent during counting of time to be again 
sent to the destination. 
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4. The device in accordance with claim 2, wherein said 
control data monitoring circuit comprises: 

a timer (220) for starting counting time in re- 
sponse to an output of the control data to there- 
by count a period of time up to a receipt of an 
answer from a destination; 
a comparing circuit (222) for comparing the pe- 
riod of time counted by said timer (220) and a 
preselected reference period of time; and 
a retransmission control circuit (224) for caus- 
ing, when said comparing circuit (222) deter- 
mines that the period of time counted is longer 
than the reference period of time, the control 
data sent during counting of time to be again 
sent to the destination. 
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5. The device in accordance with claim 4, CHARAC- 
TERIZED IN THAT the first communication stand- 
ard and the second communication standard re- 
spectively correspond to ITU-T Recommendation T. 
30 (revised in 1996) and Recommendation T. 38 
(June/1998), and wherein said first terminal unit 
(30, 120) and said second terminal unit (30, 120) 
comprise G3 (Group 3) facsimile apparatuses cor- 
responding to Recommendation T.30 ( revised in 
1996). 

6. A data output control method for a communication 
connecting device (10, 110) connected at one end 
to a first terminal unit (30, 120) and connected at 
the other end to a second terminal unit (30, 120) via 
an IP network (100), and selectively operable with 
a plurality of communication standards adaptive to 
said first terminal unit (30, 120), said second termi- 
nal unit (30, 120) and said IP network (100) for 
thereby implementing real-time communication, 

CHARACTERIZED BY comprising: 

a first step of storing data received from the first 
terminal unit (30, 120) or the second terminal 
unit (30, 120) ; 

a second step of outputting size information 
representative of a size of data to be collective- 
ly coded; 

a third step of collectively coding the data in ac- 
cordance with the read out size information and 
a first communication standard, determining 
whether or not coded data produced in the sec- 
ond step is control data for control of data, and 
outputting a notification control signal if said 
coded data is said control data; 
a fourth step of storing the coded data on the 
assumption of a loss of said coded data; 
a fifth step of reading out, in accordance with a 
second communication standard relating to the 
I P network, a header for the coded data and the 
coded data stored on the assumption of the loss 
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of said coded data, and combining said header 
and said coded data; 

a sixth step of sending the control data read out 
a plurality of times in response to the notifica- 
tion control signal, while monitoring a transmis- 
sion condition of said control data; and 
a seventh step of converting the coded data to 
a signal based on a command and outputting 
said signal. 

The method in accordance with claim 6, CHARAC- 
TERIZED IN THAT said sixth step comprises: 

an eighth step of starting counting time in re- 
sponse to an output of the control data and 
counting time up to a receipt of an answer to 
said control data from a destination; and 
a ninth step of causing the control data sent 
during counting of time to be again sent when 
the period of time counted exceeds a preselect- 
ed reference period of time. 

The method in accordance with claim 7, CHARAC- 
TERIZED IN THAT the first communication stand- 
ard and the second communication standard re- 
spectively correspond to ITU-T Recommendation T. 
30 (revised in 1996) and Recommendation T.38 
(June/1998), and wherein said first terminal unit 
(30, 120) and said second terminal unit (30, 120) 
comprise G3 facsimile apparatuses corresponding 
to Recommendation T.30 (revised in 1996). 
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